Subject: misc. flow control issues

From: [email-masked]
Date: Sun, 26 Jun 94 22:19:53 EDT

Sorry I've been out of the loop recently on flow control.  Here are a
few thoughts I wanted to get out before the meeting just in case anyone
reads their mail before the flow control discussion.

>2) Is CONNECTED the only state in which pre-standard nodes support
>   x_BUSY?
>
>   The old 6611 FSMs showed xBUSY being supported in lots of states.
>   Steve Klein's newest set removes these lines, because of various
>   agreements reached in Anaheim.  So the only language about xBUSY
>   in the AIW standard will be in the flow control part of a "back
>   level compatibility" section.  I have not polled vendors of pre-
>   standard implementations, but I suggest that this language require
>   xBUSY support only in CONNECTED state.
>
>          SN - Which prestandard implementations actually send
>          xBUSY?  In what states do they send them? Which prestandard
>          implementations actual honor xBUSY?  In what states do they honor
>          them? Do we want to support any or all of the above?

  I now realize that if an RFC1434+ node supports ENTER_BUSY and EXIT_
  BUSY only in CONNECTED state, it will have problems interoperating
  with an IBM 6611 running APPN sessions (not because of flow control,
  but because these SSP messages are used in circuit setup).  Yet there
  is no way to reference post-RFC 1434 6611 fsm's in our document.
  I think we could either:
   - decide not to have a "backwards compatibility" section at all
   - say "... supports x_BUSY messages in at least the circuit state
     CONNECTED..." and leave it up to implementations what else they
     want to support.
  Either is acceptable to me at this point, so I'd like to hear other
  opinions.

  I understand that Wellfleet and Proteon both send and receive x_BUSY,
  while the 6611 can receive them but does not send them for flow
  control but only for the condition I just mentioned.  I don't know
  what states the non-IBM boxes support.

>4) Resolve exactly which circuit states pacing operates in, and how
>   state transitions are handled.  See my exchange with Bernie Brady
>   ending on 3/14/94 about CIRCUIT_ESTABLISHED state.
>
>   After giving this some thought, I feel the scheme would be most
>   robust if it were tied only to frame types and not to circuit
>   states.  It is then absolutely clear which frames are counted
>   even if the two DLSw nodes are slightly out of sync with regard
>   to circuit states.  I would propose that DGRMFRAME and INFOFRAME
>   be subject to counting regardless of circuit state.  The only
>   place in the FSMs where this rule seems strange is DGRMFRAME
>   coming from CIRCUIT_PENDING state, but I believe this is an error
>   and should be DATAFRAME since the sending node does not have a
>   circuit id from the origin node at the time it sends the frame.
>
>     SN - I think it should be tied to certain frame types as well.
>     All frames which have meaning outside SSP, which can be
>     assigned to a circuit.
>     I also believe that the receiver should explicitly "grant" the
>     first window.  This should handle the state-stuff shouldn't it?
>     ..ie. when I'm ready to receive the frames we're going to
>     count, then I'll let you know.

  I agree that this idea in Shannon's recent proposals is architectur-
  ally "clean", but I think the extra flow it introduces before data
  can flow may be unacceptable.  In NetBIOS in particular, we have
  found that some server products time the interval from sending a
  Name Recognized until they receive a SESSION INIT (I'm not sure I have
  the right term) from the client.  Adding the delay of one more frame
  flow could cause circuits/sessions to fail to come up.

  I think the ICR or REACH_ACK that starts the circuit should also
  authorize an initial pacing state where a non-zero number of
  frames are granted.  If you're not ready, delay those, but don't
  add to the bringup time of all circuits when buffers are fine.

>5) Resolve whether a node is REQUIRED to send HALT_DL_NOACK if
>   a pacing window is exceeded (or other pacing protocol error if
>   there are any), or if this is a product choice.
>
>   I suggest this be a product choice, but I do not feel strongly
>   about this.  If anyone feels we should require a HALT..., please
>   provide a list of the protocol errors also.  I don't think it's
>   fair to require an action but not spell out the checks required.
>
>          SN - Product Choice

  Shannon, did you change your mind in your latest proposal?
  You have a list of errors and a HALT requirement.

Peter

---

From: "Shannon Nix" <[email-masked]>
Date: Mon, 27 Jun 94 08:29:14

Hi Peter,

Thanks for your comments:

>PG - 2) Is CONNECTED the only state in which pre-standard nodes support
>   x_BUSY?
>

>  PG - I now realize that if an RFC1434+ node supports ENTER_BUSY and EXIT_

>  what states the non-IBM boxes support.

          SN - I have no preference.  We can discuss this at AIW.

>PG - 4) Resolve exactly which circuit states pacing operates in, and how

>  add to the bringup time of all circuits when buffers are fine.

          SN - I would think that withholding ICR or REACH_ACK due to lack of 
          buffers would be "unacceptable".  Even if it is acceptable from a 
          protocol
          perspective, it makes the implementation (of a deterministic buffer 
          model) messier (my connection protocol now has to worry about flow 
          control)

>PG -5) Resolve whether a node is REQUIRED to send HALT_DL_NOACK if

>  You have a list of errors and a HALT requirement.

          SN - Yes, I changed my mind.  I was drafting the section that 
          described certain protocol errors and what some alternative (TO
          HALT_NOACK)  solutions might be, and I came to the conclusion
          that if the two ends don't agree on F/C protocol, then the
          reliable data link is broken, and one would be doing the end-user
          a disservice by pretending that it wasn't.

>Peter

         Shannon